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WO 01/16845 PCT/USOO/24004 
METHOD AND APPARATUS FOR NETWORK-BASED AUTOMATED 
INSURANCE TRANSACTION PROCESSING 



Background of the Invention 

The present invention relates to the field of computer and network based business 
application systems, and specifically to systems which relate to the presentation, processing, and 
maintenance of insurance products and related transactions over a distributed computer system. 

Traditionally, insurance companies have utilized paper intensive systems for the 
presentation, processing, and maintenance of insurance policies to potential clients. 
Additionally, claims processing and monetary transactions, such as bill payment or payment 
under a claim, have been accomplished largely by paper means. To initiate a policy, clients 
typically have had the choice of dealing directly with an insurance company's agent and, 
typically, being limited to that company's policy choices or dealing with an independent 
insurance agent, who may offer policy choices from a group of insurance companies. In either 
case, the process of comparing, selecting, and processing a policy is largely accomplished by a 
variety of intermediate entities using largely paper processing, and to a lesser degree some 
computer processing. Additionally, because the processing of a client's policy, once selected, is 
extremely time consuming, often about six weeks, the insurance agent is only able to provide a 
policy quote, rather than an accurate premium (or price) to the client at the time the application 
for insurance is taken. In some systems, despite some automation, a client is tentatively issued a 
policy, which is then subject to subsequent approval and possible cancellation if certain 
underwriting rules are not satisfied. 

A typical process 100 for processing a client's policy selection is shown in Figure 1 . 
Initially, a client meets with an agent to compare policies and policy options for a specific type of 
insurance policy, e.g., home or auto. Based on the information provided by a client for the 
specific type of policy, the agent generates a set of comparative price quotes, shown in step 102. 
These quotes may be generated from company hard-copy literature or from tables stored in a 
computer, wherein the agents computer configuration is often highly customized with special 
software to access and use insurance company information - which may not actually be current 
when used. As an example, a client may inquire about an auto insurance policy including 
comprehensive coverage. The client may then request different policy price quotes for the auto 
policy having different options (or elements) selected for comparison, such as having a $500 
versus a $1 ,000 deductible option or having a towing option added to the policy. Additionally, 
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tne premium ot the policy depends on unique client information, such as driving record and the 
value of the auto to be insured, and unique insurance company information, such as current 
policy rates. 

The need to process the insurance application through underwriting, including the need to 
verify a variety of factors involved in accurately determining a policy premium, makes it 
impossible for the insurance agent to produce a definite premium at the time the policy 
application is taken. Therefore, the agent can, at best, only provide the client with a price quote 
or quotes, which are merely estimates. Such a system and process results in the client having to 
leave the application process without having certain premium information. Therefore, the client 
bears an undesirable cost risk that the policy may ultimately be more costly than envisioned, 
assuming it actually issues after the underwriting process is complete. 

Once the client has selected a given policy, including any desired policy options, the 
agent prepares and submits a policy application to the insurance company (or carrier), shown in 
steps 104 and 106, and accepts a down-payment from the client. The insurance company's mail- 
room logs in the receipt of the policy application, step 108, forwards the policy application to the 
underwriting department, step 1 1 0, and forwards the client's down-payment to the company's 
billing department, step 109, where it is held until a decision regarding the issuance of the policy 
is made by underwriting. Among other things, the underwriting department verifies certain 
critical information in and related to the application. For example, the underwriting department 
may verify a client's driving record 112, credit history 1 14. and criminal record 116, along with 
applying the most current set of available underwriting rules of the company 1 18 to the 
application. The nature of such inquiries is that the data used, whether client related or insurance 
company related, may not necessarily be current, i.e. the data may be "stale". And, even if 
current, may become stale between the time of inquiry and the time of policy issuance. In such 
cases, the insurance company unavoidably assumes the risk that the factors used as the basis for 
issuing a policy are correct and that these factors do not change between the time of making the 
inquiries and the time of issuing the policy. Based on the results of these types of inquiries and 
analysis, a determination is made regarding whether a policy will issue, step 120 (i.e., meets the 
underwriting guidelines). If the policy issues, step 122, it is mailed to the insurance agent, step 
124, who then notifies the client of the issuance of the policy. 

Once a policy issues, a legal notice is issued to that effect, step 126, and a bill reflecting 
the final premium is generated. Typically, the insurance company's billing department credits 
the client's original down-payment toward the premium. If the amount of the premium is less 
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than the down-payment, then a refund for the difference is mailed to the insured client, in step 

132. However, it is more typical that after application of the down-payment, a balance remains 

and the insured client is billed in accordance with agreed upon billing terms reflected in the 

policy, step 130. From thereon, the insurance company generates a billing schedule and mails a 

5 bill statement to the client and the client returns statement with the appropriate payment. This 

process continues until the premium and any associated finance charges are paid in full. 

In the case where the policy application does not meet underwriting guidelines, the 

underwriting department rejects the policy application, step 134, and notifies the insurance agent, 

step 136. The agent then works with the client to replace the policy application with a revised 

10 application, step 138, that overcomes (if possible) the basis for rejection of the previous policy 
application, and in doing so returns to the initial step 102 of generating new quotes based on 
various policy changes. This process may be repeated until the agent and client finally arrive at a - 
policy application that results in an issued policy by the underwriting department, if possible. 
While policies are often written to retroactively provide coverage back to the date of the 

15 application, such protection is only useful to the client in the case where the policy issues. If the 
policy does not issue, the client has unknowingly been uninsured between the time of application 
and the time of rejection. 

Therefore, it would be advantageous to the client to have a system which allows for 
comparison of a variety of insurance products having a variety of selected options at one time 

20 and for immediate generation and receipt of accurate price quote information for such policies. 
Furthermore, a system which provides near-real time policy issuance would eliminate any 
significant gap in coverage between the time the client applies for a policy and the time the client 
is informed as to whether the policy has been approved for issuance. Also, a system which 
allows insurance companies to efficiently maintain and control the underwriting guidelines, 

25 algorithms, rate tables, account information and other pertinent information which is accessible 
by agents, without a high degree of computer customization required by the agents, would 
expedite the policy application and evaluation process, while also reducing risk to the carrier 
associated with reliance on stale data. 

Accordingly, it is an object of the present invention to provide a highly automated 

30 distributed computer system for dynamically accepting user information and, based thereon, 
generating unique product candidate solutions, displaying said candidate solutions, accepting 
selection of one of said candidate solutions, and storing said solution. It is also an object to 
provide computer access to third party financial institutions to allow electronic transfer of funds 
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and credit card payments, for example, to facilitate bill and claim related payments. It is a 

further object of the invention to provide access to third party information providers (e.g., motor 
vehicle, claim, and credit databases), where available, to facilitate a more efficient underwriting 
process, for example. In such a system, it is a further object to allow real or near real-time 
updates of product information. 

Summary of the Invention 

The present invention is a data driven automated insurance transaction processing system 
operating over a distributed communication network to provide real or near real-time generation 
of policy price quotes, underwriting and policy issuance, and generation of billing schedules. An 
insurance agent can login to the system over the network and gain access to a core set of engines 
(the "Core") and Framework databases, including databases containing a plurality of insurance 
provider's (or carrier's) information, and quickly provide a comparison of candidate policies and 
corresponding price quotes from among those carriers to a client. The client and agent may 
select a preferred policy from among the candidate policies and in response the system issues the 
selected policy and generates a corresponding billing schedule. Payments against the policy 
premium can be made electronically by credit and debit card, payroll deduction, or electronic 
funds transfer. Additionally, insurance claims may be filed over the network, and a claims 
adjuster and an examiner may be automatically assigned from a database of preferred adjusters 
and examiners. The system may also be configured to generate candidate policies of types other 
than that requested, using at least some of the client information provided. 

The system architecture includes a user management subsystem and the Framework 
database system (and its Core set of engines). Among other things, the Framework database 
system includes at least one static database for storing standard procedures, rules, and rate 
products and at least one dynamic database for storing data produced during a particular user 
session. The Core includes interfaces to related third party service providers (e.g., credit card 
and third party information source companies). The user management subsystem includes a 
group of software applications which may be configured for different types of users and that 
interface with the Core via the World Wide Web ("Web"), for example. As discussed below, 
some types of users may access the Core using a standard Web browser, while other types of 
users require a client-side application to be resident in their computer. Depending on the login 
privileges of a user, the substantive interface to the Core will vary. An interface is primarily 
created by the presentation of screen images on a workstation or terminal display. For example, 
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a carrier's application interface allows an insurance provider to access the Core and view their 

customers 1 accounts. An agent's application interface allows access to the Core for generating a 

client's profile information and accessing insurance carrier's databases and algorithms for 

generating policy rate quotes, selecting a policy, issuing a policy, generating a bill schedule, 

5 accepting premium payments and filing claims. A claims application interface allows access to 

the Core by claim examiner's and adjusters for processing claims, including reviewing a claim, 

tracking the claim, and issuing claim pay-outs to service provider's (e.g., repair shops) and to 

clients. A general developer's (or implementor's) system (i.e., a client-server application) 

includes several development tools that allow access to the Core databases for the creation and 

10 maintenance of the Core and related applications. Using the development tools, a rating analyst, 
for example, may create and/or enter the Web User Interface (WUI) screens, rating tables, 
algorithms, underwriting rules, associate carrier/product information with territories, generate 
help text, and enter accident and violation information on a company/product basis. Access to 
the Core is also provided for the determination of agent's commissions and for generating system 

15 reports. 

The Core includes an application interface server which acts as the interface between the 
Core and the management system. In the preferred embodiment, the application server is a WUI 
server that generally manages access to other servers and databases within the Framework to 
accomplish tasks requested by the external users. An underwriting engine within the Core 

20 accesses an underwriting rules database and applies these rules, as part of calculating a rate quote 
for a candidate policy, to input client profile information to determine whether or not the policy 
can be issued. If a candidate policy or policies satisfy the underwriting rules, a rate/quote engine 
within the Core generates a price quote for each candidate policy. A reporting engine is also part 
of the Core and generates reports concerning various system aspects and carrier based 

25 information for different users, as appropriate. Once a policy has been issued, a billing engine 
within the Core generates a billing schedule, issues bills and invoices, and applies payments 
received to existing accounts. At the center of the Core is a transaction engine which controls the 
general tasking within the Core and which processes premium transactions and payments 
transactions. Premium transactions relate to creating, modifying, renewing, canceling, or 

30 processing claims for an existing policy. Payment transactions relate to the transfer of money. 

Brief Description of the Drawings 

The foregoing and other objects of this invention, the various features thereof, as well as 
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the invention itself, may be more fully understood from the following description, when read 

together with the accompanying drawings, as described below, 

FIGURE 1 is a flowchart of a typical prior art process for processing an insurance policy 
application. 

5 FIGURE 2A is a block diagram of an insurance processing system and FIGURE 2B is a 

block diagram that includes the portions of the Framework and Core, in accordance with the 
present invention. 

FIGURE 2C is a diagram of a set of development tools included in the implementor's 
system of FIGURE 2 A. 

1 0 FIGURE 3 is a diagram of a representative page displayed at a user's workstation and 

produced by the Core of the insurance processing system of Figure 2A. 

FIGURE 4 is a table depicting a representative group of transactions performed by the 
transaction engine' of the insurance processing system of Figure 2A. 

Figures 5 A - 5F are a series of tables which illustrate how a quote is achieved by the 
1 5 insurance processing system of Figure 2A. 

FIGURE 6 is a diagram of a computer architecture embodying the insurance processing 
system of Figure 2 A. 

For the most part, and as will be apparent when referring to the figures, when an item is 
used unchanged in more than one figure, it is identified by the same alphanumeric reference 
20 indicator in all figures. 

Detailed Description of the Preferred Embodiments 

The present invention is a data driven automated insurance transaction processing system 
operating over a distributed communication network to, among other things, provide real or near 

25 real-time generation of policy rate (i.e., price) quotes from a variety of insurance carriers' (i.e., 
providers or companies) multiple lines of business, issue insurance policies, and generate billing 
schedules. The system includes capabilities to determine and present insurance policy 
information from one or more of a variety of sources to facilitate comparison and selection by an 
insurance agent ("agent") and/or a client, based on client profile information or data which 

30 describes relevant characteristics of the person or property to be insured. Additionally, the 
insurance processing system includes capabilities which facilitate efficient processing of an 
insured client's (the "insured's") claims. Using a compliment of automated processing and 
electronic data storage and transfer features embodied within the system, the present invention 
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allows for the paperless generation, comparison, and issuance of an insurance policy, as well as 

the electronic transfer of funds necessary for the payment of insurance premiums by the insured 
or the payment of claims by the insurance carrier. To accomplish this, the present invention 
provides real-time access to various external underwriting data sources, interfaces to outside 

5 services, such as policy printing and bank and credit card company systems, and is electronically 
coupled to various carrier systems. 

The insurance transaction processing system is designed to allow a developer (e.g., a 
rating analyst or specialist) to accomplish the generation and maintenance of, for example, rate 
quote products using a set of user friendly (i.e., non-technical) development tools. Rating 

1 0 analysts are individuals knowledgeable in insurance rate subject matter, and are not required to 
be skilled in computer programming. Rate quote products are used, typically by an insurance 
agent, with specific client data to generate rate quotes for that client. The ease of use of the 
system provides the ability to rapidly develop and maintain a large number of rate quote 
products, spanning multiple lines of business, and covering all states. 

1 5 In the preferred embodiment, the distributed communication network is the Internet and 

World Wide Web (i.e., the "Web") and the insurance processing system is a "Web-based" 
insurance processing system. In an alternate embodiment, the distributed communication 
network includes an extra-net (i.e., a form of wide area network (WAN)) using Web browser 
interfaces. Operating applications of the system, which implement relevant processes, and rate 

20 quotes produced by the system are delivered to users through a TCP/IP connection and a 
standard Web browser on the user's workstation. Delivering its services over the Web, the 
present invention generally minimizes costs, for example costs associated with the development 
and maintenance of the client-side workstation configuration. 

To facilitate automated processing, the capabilities of the system are embodied in a 

25 combination of computer software and hardware. The system architecture implemented in the 
preferred embodiment includes a variety of terminals or workstations which run or access 
applications which then provide access to a Web User Interface ("WUT) Server, an 
implementor's system including a set of development tools for product development and 
maintenance and a corresponding tools server, a plurality of third party interfaces, and a database 

30 system that provides the underlining system functionality, referred to as the "Framework". For 
the most part, the Framework database system drives system processes. For example, the 
Framework database system contains the information required to build the user interface screens, 
maintains state in the Web-based applications, stores all of the business and underwriting rules. 
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drives external processes which interface with remote systems, and stores business rule and 
transactional data. Each data element, whether a rule, a rate factor, a screen display element or 
some other data element is tagged with an effective and an expiration date, which allows each of 
the periodic rate and rule changes to be specifically preserved in the system at all times. Entering 
the appropriate policy effective date allows the corresponding rate, rule, and/or screen set to be 
automatically accessed at any time. 

The Framework is driven by and includes a standard set of stored procedures that provide 
core, data driven functionality, referred to as "the Core". The primary functional areas of the 
Framework are built as a series of Core "engines" and servers. As will be described in more 
detail and as shown in Figure 2A, the Web-based insurance processing system 200 includes a 
user management system 220 that interfaces with Core 230, wherein the Core also includes an 
interface to third party entities 250 and to a developer's/maintainer-s, or implementor's, system 
260. The user management system 220 includes a variety of computer terminals or workstations 
that have access to Core 230 for transaction processing. The workstations may be remote to each 
other and to the Core, wherein communication among the various workstations and the Core 
takes place over the Web using standard communication links (e.g., phone lines). While the 
preferred embodiment uses the Internet and Web as a communication medium, other types of 
networks, such as an Intranet, extra-net, local area network (LAN), WAN or a combination of 
networks could also be used. A workstation may be any commercially available desktop 
computer running a standard operating system and Web browser (e.g., Internet Explorer™ by 
Microsoft Corporation). As such, the workstations do not require any significant customization 
to access the Core. 

The WUI server 232, which is an application server, is the primary interface between 
each workstation and the servers and engines of the Core 230 and the Framework databases they 
access. The WUI server 232 may be any commercially available server configured to 
communicate across the Internet and Web with the workstations. The engines provide the 
primary processing capability of the system 200, and include the necessary logic and hardware to 
accomplish relevant insurance processing related tasks by acting on both transactional and 
business rule data stored in dynamic and static Framework databases, respectively. Data which 
identifies the client and/or item to be insured, along with any. other required client specific 
information required by the system 200, is referred to as client profile information or data, which 
is supplied by user input at a workstation during a session and constitutes at least a portion of the 
transactional data stored in a dynamic database. Data related to a specific policy, either an issued 
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or candidate policy, is referred to as policy data and includes client profile information as 

necessary, and also constitutes at least a portion of transactional data. 

A simplified database structure is shown in Figure 2B, those skilled in the art will 
appreciate that the databases may or may not be physically co-located with the engines or with 
5 each other and may be distributed over several devices and backed-up and mirrored as desired. 
Because the system is both an insurance transaction processing system and a development 
system (used for, among other things, maintenance and updates), the Framework database system 
225 design is easily extensible by using commonly available and standard devices and interfaces. 
Extensibility is also accomplished in large part through the use of vertical "objectized" data 

1 0 structures. That is, when new data elements are required, they are added as a row in a data 

element master table, not as columns in a hard-coded table structure. Data element properties are 
stored in related tables and may be configured by product, carrier, or user, for example. The 
database structure is discussed further below and with respect to Figures 2B and 6. 
I. Management System (Workstations) 

1 5 There are several types of users which may access the Core to perform, in most cases, a 

subset of available system functions. For example, typical users may include insurance agents, 
clients, insurance carriers, claims adjusters and examiners, and system developers and 
maintainers (e.g., a "rating analyst"). In the preferred embodiment, different types of users have 
different privileges. For example, insurance carrier rating analysts have privileges to create and 

20 update rate tables and underwriting rules within the Core, but clients may only have privileges to 
review an existing policy and account information, and agents may only have privileges to 
generate, renew, and review a policy. Consequently, the system 200 includes user specific 
application interfaces (i.e., computer screens and functionality) rendered on workstations 202 - 
212. Some of these application interfaces merely require a standard Web browser to access the 

25 Core, while others require user specific client-side applications. These application interfaces 
allow predetermined types of access to Core 230, each interface having functions specific to its 
corresponding type of user, based on predetermined user privileges. These workstations and 
interfaces are collectively referred to as the user management system 220. The Web browser 
application interfaces are actually generated by the Core and communicated to the workstations 

30 as hypertext markup language (HTML) code and then rendered on the workstation within a Web 
browser. 

In Figure 2A ? a group of representative user specific "applications", each running on a 
standard workstation, is shown as a simplified depiction of the preferred embodiment. However, 
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in practice, a plurality of workstations running the same application, for example, a plurality of 

workstations at different locations running agent's application 205, is more likely to be the case. 
Additionally, each workstation may run more than one type of application, such flexibility being 
a function of the login privileges of different types of users (e.g., carriers, agents, and claims 
adjusters), and wherein such users may login to and access the Core from any Web enabled 
workstation. As a general notion, types of users and access privileges may be defined in a 
variety of ways, as is known in the art. In the preferred embodiment, communication between 
the Core and each workstation takes place over the Web (and Internet) using commercially 
available hardware and software interfaces, systems and communication links (e.g., phone lines). 
Each type of user specific application included in management system 220 is described more 
fully below. 

Referring once again to Figure 2A, a claims application 202 allows a claim examiner and 
adjuster to access the Core and manage the processing of insurance claims via a Web browser. 
Claim information may initially be entered into the Core via an agent's (or carrier's) workstation 
and an examiner and adjuster may be automatically assigned to the particular claim or 
recommended from a Core database of preferred examiners and adjusters. An examiner or 
adjuster may update and manipulate claim data from a workstation running claims application 
202 during the course of claim resolution. Other users may also take part in updating or 
providing claim related data, such as an agent or carrier. Furthermore, an adjuster may facilitate 
payment of a claim electronically by transferring funds from the carrier's bank to the insured's 
bank or to the bank of a service provider. A service provider may be any entity involved in the 
repair, replacement, or resolution of the subject matter of the claim, such as an auto repair person 
or shop. 

A carrier's application 204 is a compliment of carrier screens and functionality displayed 
and available within the Web browser of a workstation and which allows a carrier to access the 
Core directly for carrier specific purposes. The carrier's application 204 provides access to the 
Core to allow the carrier to update carrier information, such as rate tables and underwriting rules 
stored in the static Framework database 255. The carrier's application 204 also allows the carrier 
to access and manipulate existing policy and account information (stored in the long term 
database 265), accomplish payment transactions, generate new policies, and so on. 

An agent's application 205 is a compliment of screens and functionality displayed and 
available within the Web browser of a workstation to allow an insurance agent to generate price 
quotes, have policies issued, query existing policies, and process claims, for example. In 

10 
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practice, the actual privileges associated with an agent's workstation may vary depending on a 

variety of factors. For example, it may be the case where an agent may only be authorized to sell 
products from a certain carrier or carriers, while other agents may be authorized to sell products 
offered by any available carriers. It is envisioned that workstations or terminals running the 
5 agent application will be located at various locations where agents service the needs of existing 
and potential clients. For example, access to the system of the present invention may be 
franchised to agents and agencies, wherein agent workstations may be located in any of a variety 
of locations as franchise locations. Such locations may include traditional agency offices or non- 
traditional forums such as retail store or wholesale club locations, as a means of improving the 

10 consumer's accessibility to such insurance related services and products. 

A data access application 206 is a compliment of screens and functionality displayed and 
available as a client-side application running on a workstation that is used for accessing and 
extracting data from and storing data to the management system 220. The data access 
application 206 may be used by any of a variety of users to obtain reports and data consistent 

1 5 with the user's privileges. For instance, data (e.g., system performance measures) may be 
extracted from the Framework database system by a system manager using the data access 
application 206 to determine if system performance is acceptable. 

A system manager's application 208 is used to generally maintain the Core 230, e.g., keep 
applications, frameworks, utility versions, and so on up to date via a Web browser. The system 

20 manager can monitor system performance and tune the system by adjusting, to some degree, the 
allocation of system resources (e.g., processors and memory). 

A commissions application 210 is a compliment of functionality and screens accessible 
on a workstation that is interfaced with a call center and agency application 2 12 to accomplish 
up-to-date commission processing and maintenance of commission rates within the a carrier's 

25 call center or an agency. The call center and agency application 212 logs on to the Core to 
retrieve information related to the determination of an insurance agent's earned commissions, 
such information being maintained within the Core as part of typical transaction processing. 
II. The Core 230 

The Framework database system provides the primary functionality and data storage 

30 capability of the preferred embodiment of the present invention, and it is the Core 230 of the 

Framework which provides the functionality, as shown in Figure 2B. Core 230 accesses a series 
of Framework databases which store data, such as business and underwriting rules for each 
insurance carrier (in database 255), client policy and account information (in database 245 and/or 
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*>5), and all other necessary business and transactional data. In the preferred embodiment, the 

Framework databases are object-centric relational Structured Query Language (SQL) databases, 
version 6.5. SQL databases are known in the art and are not discussed in detail herein. For the 
most part, Core 230 includes a series of stored procedures that provide data-driven functionality, 
referred to as "engines" and servers. As examples, the engines and servers use the data in the 
Framework databases to build user interface screens, generate policy information and quotes, 
issue, store and maintain policies, and accomplish claims processing. These engines and servers 
include: billing engine, rate/quote engine, reporting engine, tools server, transaction engine, 
underwriting engine, and WUI server. Generally, the servers provide interfaces between external 
users and the Core and the engines accomplish tasks in response to server requests. The Core 
includes external interfaces to the management system workstations and to third party systems 
for performing a variety of ancillary insurance transaction functions, such as electronic funds 
transfer, credit/debit card authorizations and transactions, and lock box processing. Core 230 
also includes an interface to implementor's system 260, which includes a set of development 
tools for the creation of WUI pages, rate tables, underwriting rule databases and so on, as well as 
general maintenance of the system. Each engine and server is described below, 
a. WUI Server 232 

The WUI server 232 is the primary interface of external users to the Core for processing 
insurance transactions. In the preferred embodiment each WUI server is a commercially 
available server running Windows NT™ Server 4.0 software, by Microsoft Corporation. The 
WUI server 232 includes functionality which generates and communicates, in real-time, HTML 
computer screen information corresponding to a screen image to be rendered at a user's 
workstation during a session. When the HTML screen information is received, the user's 
workstation processes the information using a standard Web browser to produce and present the 
desired screen image. As the interface to the workstations of the management system 220, the 
WUI server controls user privileges, as a function of the user's login, for accessing the Core. 

More specifically, the WUI server 232 extracts rules from the Framework databases, as 
shown in Figure 2B, guiding which graphic, data, and functional elements are to be displayed 
then dynamically builds pages according to a predefined general layout. As a result, system 
performance is enhanced, wherein the WUI server 232 generates screen information dynamically 
in response to user inputs, such that the next screen to be displayed is a function of the client 
profile information and responses input in the current (and previous) screens, as well as the 
business and underwriting rules stored within the Framework databases. Building screens 
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dynamically involves generating and sending software code from the WUI server 232 to a 

workstation, wherein the Web browser running on the workstation compiles the code (e.g., 
HTML code) and builds the screen therefrom. The preferred embodiment employs software 
written using a commercially available server-side scripting software language, such as 
5 ColdFusion® (by Allaire™ Corporation), to accomplish the dynamic generation of screen 

images processed and displayed by the Web browser, using data from the Framework databases. 
Therefore, once the user submits responses to the WUI server 232 (via a workstation) the server 
executes the server-side scripting language (which is an application) to quickly generate HTML 
code, which is then sent by the WUI server back to the workstation and Web browser of the user. 
10 The Web browser running on the workstation then builds the appropriate screen using the 
HTML code. 

To start a session, a user logs on to WUI server 232 via the Web using the standard Web 
browser interface. The user may, for example, be an agent working with a client to obtain policy . 
information and compare policies or a user may be a client seeking to review the status of an 

15 existing policy. In other embodiments, the client may be given the flexibility to compare and 
have policies issued without the use of an agent. Using agent's workstation 205 and WUI server 
232 generated screens, the user enters client profile information (or client data) to define the 
client and/or property to be insured to the system 200 and to identify the type of policy or 
policies of interest, which is stored in transactional database 245 during the agent's/client's 

20 session. Client data identifies the client and subject matter of the policy of interest and includes, 
for example, the client's name, age, and address, and also includes any basic information 
necessary for the system to generate one or more policy rate quotes for the type of policy of 
interest For example, this basic information may include the make, model, and year of an 
automobile to be insured. In addition to generating computer screen information, the WUI server 

25 232 manages the flow of information in and out of the Core, and (along with the transaction 

engine 236) the assignment of tasks to engines and the storing of data into Framework databases. 

Through the WUI server 232, users remotely perform a variety of transactions, such as 
obtain policy rate quotes, access billing information, and process claims. To facilitate the input 
of relevant information for processing a transaction, the WUI server 232 incorporates a 4-level 

30 hierarchical tree structure within the screen images, including pages 300, sections 305, questions 
3 1 0, and options 3 1 5 (the lowest level), as shown in Figure 3. That is, a page contains sections, 
sections contain questions, and questions contain options. As an example, page 300 in Figure 3 
relates to an automobile policy and the input of client profile information. A page is an 
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electronic graphical equivalent (i.e., screen image) of a physical page of data. A section 305 

divides apage 300 into sets of questions 310. A question 310 solicits a response and, thereby, 

obtains information for the Core transaction processing. A question may be visible or hidden,' 

wherein a visible question may ask for date of birth and the hidden question may compute age 

therefrom. For the most part, responses to questions are stored in dynamic transactional database 
245. 

Each question is assigned a data type to define the form of the response, which 
corresponds to a data definition within a Framework database. In the preferred form, data types 
include free text, drop-down list, and button. A data type of free text relates to a question that 
requires a free text response typed into a corresponding answer field. A data type of drop down 
list means that the question requires the response be selected from a corresponding list of 
responses (i.e., options 315). A data type of button refers to a question that is displayed as either 
a button or hyperlink, which when clicked submits a request for a new page to the Web browser. 
Questions may also include formulas, typically embodied within the servers and engines, that 
aid in the generation of the code corresponding to the next page to be submitted to the 
workstation. For example, if a user selects the option "Under 25 years of age", then the code 
generated for the next page submitted will be different than if the user selected the option "Over 
25 years of age". Those skilled in the art will appreciate that other forms of input data types may 
be used, such as graphical sliding scales, audio/voice data input! and so on, without departing 
from the present invention. 

In practice, once the user has logged into the Web server 232, the Web browser running 
on the remote user's workstation submits a request for a page to the WUI server 232. The WUI 
232 server analyzes the request and returns the appropriate screen image code and data to the 
workstation, assuming the request is consistent with the user's privileges. The WUI server 232 
passes user requests and associated tasking to the transaction engine 234 (as shown in Figures 2A 
and 2B), which then tasks the other Core engines and servers to accomplish tasks related to the 
user's request, some of which may involve the Core obtaining information from third parties. For 
example, if a user is seeking to obtain rate quotes for a new auto insurance policy in 
Massachusetts, Core 230 may be configured to automatically request the client's driving record 
from the Massachusetts Registry of Motor Vehicles, assuming it is available on-line, and such 
information may be used in determining whether the client is insurable and, if so, comparative 
policy rate quotes are generated, 
b. Transaction Engine 234 
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The transaction engine 234 receives user transaction requests via the WUI server 232 and 

serves as the central director and manager for processing within Core system 230, as shown in 
Figures 2A and 2B. In response to workstation requests by a user, the WUI server 232 passes the 
user's request to the transaction engine 234 for processing. The transaction engine then controls 
the processing of the transaction using the other engines and servers within the Core 230 and 
Framework databases as needed. In the preferred embodiment, transactions primarily fall into 
one of two groups, either premium transactions or payment transactions. Premium transactions 
potentially effect the policy premium. The types of transactions in the premium transaction 
group include: new business (i.e., policies) and policy amendments, changes, endorsements, 
renewals, cancellations, rescissions, terminations, non-renewals, and claims processing. 
Payment transactions involve the transfer or exchange of money, and the group includes billing 
termination and resumption, premium returns, receipt of payments (including cash), transfers of 
funds electronically, and write-offs. A representative list of actions (i.e., transactions) and 
descriptions preformed by the transaction engine 234 in the preferred embodiment is provided in 
Figure 4. Generally, each type of transaction is customary in the insurance business and will not 
be explained in detail herein and, in fact, most are self-explanatory. 

The transaction engine 234 includes three managers, which are embodied in stored 
procedures and data (associated with, for example, rating server 630a of Figure 6) used for 
processing transactions, and serves as the central processor of the WUI server 232 requests. As 
such, the transaction engine 234 interacts with other severs and engines within the Core and 
Framework databases, as required. The transaction engine 234 includes a transaction manager, a 
quote manager, and a policy manager, in the preferred embodiment. Generally, the managers 
respond to user manipulation of a WUI screen (e.g., answering questions) at the user's 
workstation to create, modify, or view a policy, for example. As part of a user's request, the 
WUI Server 232 assigns a value ("Q" for quote or "P" for policy) to a "transaction type" 
parameter associated with the user's request. The WUI server 232 calls transaction engine 234 
which invokes the transaction manager to service the user's request for a transaction, using 
procedures, rules, and rate products in database 255. In the preferred form and as shown in 
Figure 2B, the standard procedures, rules, and rate products are stored in substantially static 
database 255 and transactional data (e.g., client profile data and rate quotes) associated with a 
particular user's session are stored in a dynamic (or relatively temporary) database 245. It shouid 
be understood that databases 255 and 265 are not truly static, in that they are updated from time 
to time, for example, when a carrier issues new rate products. However, with respect to the 

15 



. WO <™«"/ PCI7US00/24004 
session onented dynamic database 245, databases 255 and 265 are relatively static. 

Based on the value of the transaction type parameter, the transaction manager directs the 
request to either the quote manager or the policy manager. If the user has requested comparative 
policy rate quotes the transaction type parameter is set to "Q" and the transaction manager 
invokes the quote manager to operate on the request by interacting with the rate/quote engine 
236. The quote manager saves information from the front-end (i.e., workstation) to a quote 
repository in dynamic database 245 for use by the rate/quote engine and retrieves information 
from the repository for use by the front-end. Once the rates are determined by the rate/quote 
engine, the quote information is passed from the rate/quote engine 236 to the billing engine 242 
(but staying within database 245), where a billing schedule is automatically generated. 

If the quote type parameter is set to "P" and a policy already exists, the transaction 
manager invokes the policy manager to retrieve the requested policy and, subsequently, desired 
policy actions (e.g., renew) may be accomplished. On the other hand, if the quote type parameter 
is set to "P" and a policy does not exist, the transaction manager invokes the policy manger to 
create a new policy image into which the client profile data is merged, and processing is passed 
to the rate/quote engine 336 for generation of a rate quote, which is stored in transactional 
database 245 until the policy is issued or the session is ended, 
c. Rate/ Quote Engine 236 

The rate/quote engine 236 provides the client and agent with a quote, or bottom-line 
price, for an insurance product or products. The rate/quote engine is a set of back-end procedures 
and tables in static database 255 that perform mathematical calculations. The engine 236 
matches rating elements with client profile information in dynamic database 245 to calculate 
"components", which are the building blocks of a quote. Premiums are calculated for each 
component and the sum of all premiums is presented as the quote. For the most part, there are 
three parts to the rate/quote engine 236: client profile information, rate product algorithms, and 
quotes. Client profile information (i.e., client data) is information stored in database 245 about 
the client that is entered at a workstation into the WUI server 232 by the user, as discussed 
previously. The rate product algorithms are stored in database 255 and used to calculate rate 
quotes, each carrier may have their own algorithms and each policy type and policy option 
offered by each carrier may have a unique set of algorithms. A quote is the policy cost at a given 
point in time. And, rating elements are carrier defined rates for individual coverages. 

A component is the mathematical representation of a coverage, which, when combined 
with other components, comprises the total premium. For any component, there can also be sub- 
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components. For an item to be a component of a coverage or total premium, it must be 

computed before the coverage or total premium is computed. While components are 
mathematical expressions, formulas determine the amounts that comprise the components. Since 
the determination of one component may be used to determine another component, components 
5 are processed in a deliberate order, referred to as the "rate sequence." 

To understand how components and a rate are calculated, it is useful to know how carrier 
manual details (rates, algorithms, etc;) are mapped to formulas and components. As an example, 
Figure 5 A shows a table of the bodily injury (BI) rating elements listed in an insurance manual 
for a hypothetical carrier XYZ. BI is just one of the numerous rating elements that make up the 

10 total premium. The left column (a through k) lists the elements that make up the BI rating 
component. The right column (A through J) lists the component calculations (or formulas). 
With the above information, a tree-diagram is created which represents how the rating elements 
are to be processed. This tree is created by starting at the first element to be processed (i.e., Base 
Rate x Territory Relativity) and diagramming the components until the last element is included. 

15 Figure 5B shows the resulting tree-diagram 510. Once the tree-diagram 510 has been created, 
the rating elements can be entered into the system, applying formulas to components and 
assigning rate sequences. 

A rate sequence is a number assigned to each element and represents the order in which 
elements are processed in order to calculate the total premium. For example, if there are two 

20 components, Territory Relativity and Multi-car Discount Factor, and the Multi-car Discount 
Factor needs to be multiplied by a number that includes Territory Relativity in its formula, 
Territory Relativity will have a lower rate sequence than Multi-car Discount Factor. In this case, 
the rate sequence assigned to the Base Rate times Territory Relativity is 70, and the sequence 
assigned to Multi-car Discount Factor is 35. This way, the components that make up the Multi- 

25 car Discount multiplier (which includes Territory Relativity) can be processed first. It is 

preferable to have a unique rating sequence for each component, but the rate sequence number 
need not be unique. For example, two unrelated questions, both with a rate sequence of 70, will 
be processed in an arbitrary order as determined by the system immediately after questions with 
rate sequences of less than 1 0. 

30 The rate/quote engine inverts the tree-diagram of Figure 5B, as shown in Figure 5C, and 

starts processing at the lowest level of the tree. In this example, components with rate sequence 
60 are the individual coverage premiums. Components with rate sequence 70 are the sums of 
these premiums and many other factors that may be applied (e.g., car rental factor). Rate 
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sequence 80 sums all the components, resulting in the total premium. 

Components are calculated using rates and factors, which are based on coverage choices 
and associated limits and the client profile information. Figure 5D shows the base rate and the 
factors for the BI coverage, as defined by the hypothetical carrier XYZ. The base rate is 
5 dependent on Territory and other similar client-related information. To illustrate how rating is 
done, the BI premium is calculated, as an example, using a specific hypothetical client profile. In 
this example the client profile information is such that the client: 

a) chooses 25/50 BI coverage, 

b) lives in territory 5, 

10 c) is thirty-five years of age 

d) drives a car for pleasure (non-business), 

e) has one Driving Under the Influence conviction and one violation, 

f) would like to increase his limit factor, 

g) owns one car that is rated as having "intermediate" performance, 
1 5 h) also has a homeowner's policy, 

I) always uses his car, and 
j) will pay semi-annually. 

Figure 5E shows how the rates are assigned to this client profile for the BI coverage. The 
factors are calculated and shown in Figure 5F, wherein the total BI premium is $853. This 
premium is ultimately added to the premiums for other coverages (not shown), resulting in the 
total policy premium. In this example, there is one car and one driver. If a policy has multiple 
cars and/or drivers, the rate/quote engine will process a component calculation for each. 

A temporary Framework database location, i.e., dynamic database 245, holds each 
premium, that is each component calculation. The premiums for each component are summed to 
produce the total policy premium. The total policy premium is the quote, before issuance. In the 
preferred embodiment, two tables (i.e., databases) are populated when the actual rate/quote 
transaction occurs, a premium table and a question table. The premium table is where premium 
information is stored for each component calculation and includes effective and expiration date 
tags, since a rate quote will only be valid for a fixed amount of time typically. Ultimately, the 
question table is used to save the answers associated with each component; this table stores the 
information used to obtain the quote. A policy (or total premium) quote is based on client profile 
information and the business climate at a specific moment in time. If the quote is accepted by 
the client, it is stored in permanent database 265 and made into a policy. If the quote is not 
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accepted, it may be saved in temporary database 245. In a comparative rating environment, there 

may be many quotes from multiple carriers stored. 

The system may be configured to generate candidate or recommended policies of types 
in addition to the policy type for which the initial quotes were sought. In such a case, it would be 
5 preferable, but not essential, that the system generate such candidate policies and quotes based • 
solely on the client profile information input to obtain the initial quotes. As an example, if a 
client and agent requested quotes for an automobile policy, the system can search the Framework 
databases to determine whether the client has an existing homeowner's policy and, if not, the 
system generates and offers comparative homeowner's quotes to the client, in addition to the auto 
10 quotes. 

d. Underwriting Engine 238 

Generally speaking, underwriting is the process in which a carrier assesses the risks of 
insuring the client and determines whether to offer insurance based on that assessment. 
Underwriting rules exist in an underwriting rules database of the Framework for each type of 

15 policy offered by each carrier, such as database 255. The underwriting engine 238 and rules are 
accessed by the rate/quote engine 236 in response to a request for a rate quote, such information 
and rules being used to facilitate the generation of a rate quote for a given carrier. In the 
preferred form, the rate/quote engine 236 tasks the underwriting engine 238 to apply rules before 
a quote is actually calculated. That is, once it is clear that the carrier would underwrite the 

20 candidate policy, the rate quote is prepared and initially stored in transactional database 245. 

e. Tools Server 240 

The key to developing applications with the system is a development tool set included as 
part of the implementor's system 260. The development tool set shields an application developer 
from the underlying table structures and stored procedures of the system and provides a user 

25 friendly, rapid development environment for building and maintaining rate quote products. For 
the most part, tools server 240 is accessed and used by the implementor's system 260 as an 
interface to Core 230. The tools server 240 is, therefore, a development and maintenance server 
which includes the functionality to process inputs from a developer or maintainer (e.g., rating 
analyst) to create and edit WUI pages, sections, etc. and to create carrier products (e.g., rate quote 

30 products). 

f. Billing Engine 242 

The billing engine 242 generates a billing schedule, that is, a schedule of payments, 
issues bills and invoices, and applies payments. The billing engine 242 accesses third party 
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tmancial institutions to accomplish any of a variety of monetary transactions, as appropriate. 
Monetary transaction methods include, for example, payroll deductions, electronic funds 
transfers, and credit/debit card transactions, 
g. Reporting Engine 244 

The reporting engine provides carriers, agents, and system managers with reports on 
various aspects of the system through the various applications. Such reports generally provide 
business management information. For example, the following reports are provided to the 
following types of users: 

a) to carriers: new business, renewals, written/earned premium, claims etc.; 

b) to agents: those of part a) above plus commissions; 
and c) to system managers: same as part b). 

III. Other Interfaces 

a. Implementor's System 260 

The implementor's system 260 is used by developers (e.g., rating analysts) to create and 
maintain rating products (see Figures 2A, 2B, 2C and 6) stored in the static Framework database 
255 and used by the Core's rate/quote engine 236. The implementor's system 260 includes 
several development tools (or tool modules), shown in Figure 2C, in the preferred embodiment, 
which are stored in static database 255. These development tools include a web user interface 
tool 261 that is used to design and layout WUI screens or pages, such as the computer display 
screens accessed by an agent when requesting an insurance policy rate quote from the system 
200. Such screens include information and questions which prompt the agent to enter client 
profile information required to provide a policy rate quote. A rating tool 262 is used to enter 
basic rates into rate tables and to enter and store rate algorithms and procedures. These rates, 
algorithms and procedures are associated with rating questions, which ultimately are presented to 
a user in WUI pages, wherein the responses are used for determining the final rate quotes. Each 
carrier determines their own rates and algorithms and those are built into Core 230 using the 
rating tool 262. An underwriting tool 263 is used to enter carrier specific underwriting rules as 
logical formulas into static Framework database 255. A territory tool 264 is used to enter the 
specific territories and corresponding rate factors used by the rating engine, per company and per 
product. Accordingly, territory codes are associated with ZIP codes corresponding to the 
geographic area or areas for which insurance coverage can be obtained. Generally, a rate quote is 
a function of the rates, algorithms, and rate factors for the geographic area or territory in which 
the policy is to be issued. For example, a carrier's basic rate for a certain policy may be $1 00 
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which then gets multiplied by a factor of 1 . 1 for a given geographic territory to produce a final 

rate quote of $110. 

The ability to generate useful quotes is, of course, dependent on the sufficiency and 
accuracy of the user's inputs. Therefore, a question help tool 266 is used by the rating analyst to 
5 enter help text for each question to be included in the WUI screen displays. A violations tool 
267 is used for auto, motorcycle, and boat rate products, to specify the accidents and violations 
that the insurance carrier tracks for the purpose of rating each insured driver/operator. In the 
preferred embodiment, a specific violation code (SVC) mapping tool 268 is used to map standard 
violation codes, accessed via ChoicePoint Inc., to company specific violation codes for auto, 

10 motorcycle and boat rate products. An unacceptable vehicle tool 269 allows a rating analyst to 
specify the make and model of each vehicle that each insurance carrier does not insure for auto, 
motorcycle, and boat rate products. The information entered via tools 267-269 is also used in 
calculating rates, for the appropriate types of policies. 

As will be appreciated by those skilled in the art, various development tools may be 

1 5 defined which embody the basic functionality (or modifications thereto) of the development tools 
described herein without departing from the spirit and scope of the present invention. The tools 
described herein are intended to be illustrative and not exhaustive, 
b. 3* Party Interfaces 250 

Third party interfaces 250 include interfaces to a variety of entities and services useful in 

20 automating the transaction processing of the insurance processing system 200. More 

specifically, the third party interfaces are responsible for retrieving underwriting verification data 
from industry specific service bureaus, transferring policy data to carriers, and importing data to 
system Framework databases from carriers for the purpose of billing and claims inquiry. Such 
third parties also include banks (as shown in Figure 6) and credit card companies, as well as 

25 other financial institutions, accessed for electronic fund transfers, payroll deductions, credit card 
charges and so on to pay premiums and other insurance related expenses or to issue refunds or 
payouts. Third parties may also provide financial information. For example, the system may 
interface with First Data, Inc. for real-time credit card authorizations. As another example, the 
system may include interfaces to state or federal agencies having information relevant to the 

30 insurability of a client, perhaps criminal or motor vehicle database information. One example of 
a commercially available database interfaced by the preferred embodiment of the insurance 
transaction processing system 200 is provided by ChoicePoint, Inc., which provides real-time 
access to motor vehicle registry data for about thirty states, presently, and also provides credit 
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history as well as claim history information for automobiles and personal m^^^ 
database interfaced by the system is made available by Trans Union Inc., which provides 
individuals' credit scores. To obtain such data, the WUI server of the present invention provides 
a "COM" object over the network to relevant third parties, wherein the object includes built-in 
methods used to request information from the data and service providers to which they link. It is 
envisioned that such third party information would become increasingly available and that the 
present invention incorporates interfaces to such increasingly available databases and sources. 
IV. Architecture 

Figure 6 shows a preferred architecture 600 which implements the insurance processing 
system 200 shown in Figures 2A and 2B. The server topology is configured as two networks. A 
first network 605 is routed to external networks for user access, and a second network 61 0 is a 
non-routed internal network for database access. The front-end WUI servers 232a-c are multi- 
homed with one network interface to the routed network 605, and a second network interface to 
the non-routed, back-end SQL server network 610. All Framework data are maintained in back- 
end dedicated SQL servers 620 and 630a-b that are single-homed, not routed. The third party 
interface server 650 runs system custom software to access 3- party data sources 655 linked to 
the database network 610. 

The front-end WUI servers may be duplicated as required for scalability, and are 
clustered for high availability, preferably using a "cluster CATS" solution from Allaire, Inc.. 
The back-end SQL servers are also clustered and all systems run with mirrored hot swapable 
drives and redundant power supplies, for high availability and fault protection. The Framework 
includes a collection of individual SQL server databases that may be run on multiple separate 
computers, as load balancing demands. Load is distributed among these sources based on user 
logon and therefore may be grouped in logical units, such as all agents in one or more states. 
The databases shown in Figure 6 depict a physical implementation of the static and dynamic 
databases of Figure 2B. Wherein, temporary databases 624, 636a and 636b correspond to 
dynamic database 245 of Figure 2B and the remaining databases of Figure 6 correspond to static 
databases 255 and 265 of Figure 2B. 

With more specific regard to the preferred embodiment shown in Figure 6, each WUI 
server 232a-c is actually a cluster of individual servers, with each WUI server supporting one 
database server. Generally, each WUI server cluster is paired with a database server and 
typically designated for a specific type of user, but this need not always be the case. For 
example, WUI server cluster 232a is designated for general management application serving, that 
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is, it is not designated to any specific type of user (see discussion related to workstations 202, 

204, and 208 in Figure 2A). WUI server 232b is designated for call center rating and WUI server 
232c is designated for agency rating (see discussion related to workstations 210 and 212 in 
Figure 2A). Those skilled in the art will realize that either more or less WUI servers 232 could 
5 be included in the architecture 600 and dedicated to one or more sub-groups of users in a variety 
of configurations. 

A plurality of rate product servers 630a-b are included within the architecture and are 
accessed by their associated WUI servers 232a-b respectively. While only two rate product (i.e., 
"QUOTE Services") servers are shown in Figure 6, there can be any number of rate product 

10 servers, wherein a rate product server can be associated with a given state, carrier, or line of 
business. Each rate product server 630a and 630b includes a corresponding general database 
management Framework 632a and 632b, respectively, including a series of general utilities and 
information 634a and 634b used by the server to assist in the generation of rate quotes. Also 
included with each server as part of the Framework is a temporary data storage area 636a and 

15 636b, each of which is used as a repository for data while the rate quote is being prepared. 

Information that may be stored in such an area includes client profile information and candidate 
policy information. Once a candidate policy is chosen (i.e., a preferred policy) and a policy is 
issued, that policy is stored in a permanent (or long term) memory location, such as database 265 
of Figure 2B. 

20 The architecture of Figure 6 also includes a report application server 640 which hosts a 

variety of applications for producing reports used in the general monitoring and maintenance of 
the system and for analyzing carrier and agent related information including client account 
information. Additionally, there is a third party interface server 650 which is used, for example, 
by the billing engine 242 and underwriting engine 238 of the Core. As an example, the billing 

25 : engine may use the third party interface server to exchange information necessary to conduct 

electronic fund transfers with a bank or between banks 655, or among other financial institutions. 
The third party interface 650 is also used to access data from information providers during the 
underwriting and rate quote process to verify or obtain client profile information, depending on 
the availability of on-line resources. 

30 The system is maintained on a single set of servers, preferably, and delivered via an IP 

connection and a browser. Consequently, maintenance and software version control is greatly 
simplified. For example, when a carrier issues a modified set of rates or underwriting rules, the 
new rates are entered into the system "development" area, then moved to a "staging area" for 
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Quality Assurance (QA) review, and ultimately released to the production servers where they 
then become available for use by agents, clients, and so on. The development area refers to : 
off-line development environment where manipulation, formatting, and testing of code i 
accomplished, as needed, using system tools as preparation for releasing the new rates and/or 
rules as software code to the production system 200. Once the development team is satisfied that 
such code is ready for release, the code is moved to the staging area which models the production 
system, and QA provides verification of the code's readiness. Because a single set of servers is 
used, release to production by QA accomplishes a simultaneous upgrade for all users. 
Additionally, the reliance on commonly available and standard computers and interfaces (e.g., 
Windows NT servers, SQL server databases, Web browser interfaces, and so on) and the ability 
to seamlessly add additional servers to support additional users results in an architecture with 
relatively unlimited scalability. 

The invention may be embodied in other specific forms without departing from the spirit 
or central characteristics thereof. The present embodiments are therefore to be considered in all 
respects as illustrative and not restrictive, the scope of the invention being indicated by 
appending claims rather than by the foregoing description, and all changes that come within the 
meaning and range of equivalency of the claims are therefore intended to be embraced therein. 
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1 1 . An insurance transaction system for processing transactions related to new or existing 

2 insurance policies across a remote communication network by a user, the insurance 

3 transaction system comprising: 

4 A. at least one computer workstation having a display screen and an input device, by 

5 which the user interacts with said insurance transaction system; 

6 B. at least one database having insurance rating information and underwriting rules 

7 stored therein for a plurality of insurance carriers; 

8 C. an application server, including: 

9 I. an application interface, which generates initial and subsequent prompts at 

1 0 said workstation for the user to input client data associated with a specific 

1 1 client, wherein said subsequent prompts are dynamically generated as a 

12 function of previous client data inputs at said workstation; 

13 ii. a quote generator which, as a function of said client data inputs, said rating 

14 information, and said underwriting rules, generates data representations, 

1 5 including rate quotes, of one or more candidate policies of a selected 

1 6 insurance product type from the plurality of insurance carriers; 

17 iii. a display generator which displays at the display screen said candidate 

1 8 policies for comparison, if more than one candidate policy has been 

1 9 generated by said quote generator, and selection of a preferred policy from 

20 said one or more candidate policies by said user using the input device; 

21 iv. a policy issuer which, as a function of the user's selection of a preferred 

22 policy, establishes in said database an issued policy corresponding to said 

23 preferred policy and correlated to said client; and 

24 v. a billing generator which generates and stores in said database an 

25 electronic billing schedule corresponding to said issued policy; and 

26 d. a communication network which interconnects said workstation with said 

27 application server and said database. 

1 2. The insurance transaction system of claim 1 wherein the database includes rating 

2 information and underwriting rules for at least one other type of insurance product and 

3 the quote generator includes a companion quote generator which, as a function of said 
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client data inputs and said rating information and underwriting rules for at least one other 
type of insurance product, generates data representations of one or more candidate 
companion policies from the plurality of carriers. 

The insurance transaction system of claim 1 wherein the communication network 
includes the Internet. 

The insurance transaction system of claim 1 wherein the communication network 
includes the World Wide Web. 

The insurance transaction system of claim 1 wherein the communication network 
includes at least an extra-net or an intra-net 

The insurance transaction system of claim 1, wherein the application server further 
includes: 

vi. a payment processor which accepts electronic funds transfer information 
input at said workstation, including a payment amount to be transferred 
from an identified financial account associated with said client and client 
policy identification information which identifies a policy to which the 
payment is to be applied; and 

vii. a bill updater which applies the payment amount to a balance of the 
identified policy and recalculates the balance and generates a revised 
billing schedule as a function of the application of said payment amount. 

The insurance transaction system of claim 6, wherein the said electronic funds transfer is 
of the type from the group comprising payroll deduction, direct payment, and electronic 
bill payment. 

The insurance transaction system of claim 1 , wherein the application server further 
includes: 

vi. a payment processor which accepts credit card information input at said 

workstation, including a payment amount to be credited from an identified 
credit card account associated with said client and client policy 
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identification information which identifies the policy to which the 

payment is to be applied; and 
viL a bill updater which applies the payment amount to a balance of the 
identified policy and recalculates the balance and generates a revised 
billing schedule as a function of the application of said payment amount. 

The insurance transaction system of claim 1, wherein a subset of said underwriting rules 
and rating information residing on said database relates to each carrier, and said subset is 
accessible and maintainable independently by the carrier to which the subset corresponds 
and across the computer network. 

The insurance transaction system of claim 1, wherein the system is adapted for the 
processing of an insurance claim in accordance with a client's existing policy issued by an 
insurance carrier and stored in said database, wherein a subject matter of said claim 
identifies the situation to be remedied or damage to be repaired under said claim, and the 
database includes information corresponding to a set of preferred providers for providing 
services related to remedying said situation or repairing said damage and a set of 
insurance adjusters for assessing the monetary claim value associated with said remedy or 
repair under said policy, wherein the application server includes: 

vi. a claims input interface, which generates prompts at said workstation for 
the input of client claim data, including the subject matter of said claim 
and identification of the client's existing policy in said database; 

vii. an adjuster assigner, which assigns an insurance adjuster to said claim, the 
assignment being a function of a set of predefined adjuster criteria stored 
in said database and said claim data; and 

viii. a provider assigner, which assigns at least one preferred provider from said 
set of preferred providers to said claim, the assignment being a function of 
a set of predefined provider criteria stored in said database and said claim 
data. 

The insurance transaction system of claim 10, wherein the application server further 
includes: 

ix. a claim payment processor which electronically transfers a payment 
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amount derived from said claim value from a carrier financial account of 

said insurance carrier to a preferred provider financial account of said 

preferred provider. 

The insurance transaction processing system of claim 1 , further including: 
e. a framework database system which includes said at least one database as a 
substantially static database. 

The insurance transaction processing system of claim 12, wherein said framework 
database system includes objectized extensible databases. 

The insurance transaction processing system of claim 12, wherein said framework 
database system includes at least one. dynamic database for storage of transactional data, 
said transactional data including session oriented data comprising at least said client data 
and said candidate policies. 

The insurance transaction system of Claim 1, further including an implements system 
comprised of a workstation and a plurality of development tools usable to create at least a 
portion of said application interface and to enter and store in said database said insurance 
rating information and underwriting rules from a graphical user interface, wherein each 
development tool includes program code stored and executable on said workstation. 

The insurance transaction system of claim 15, wherein said application interface is 
comprised of a plurality of display screens and said development tools include a web user 
interface tool configured to layout said display screens and generate corresponding 
program code and wherein said display screens include said application interface initial 
and subsequent prompts. 

The insurance transaction system of claim 16 wherein the display screens are pages which 
are segmented into one or more sections, and wherein each section may include one or 
more questions and each question may include one or more options. 

The insurance transaction system of claim 17, wherein said development tools include a 
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question help tool configured to enter and associate with each question explanatory help 

text to facilitate a user's accurate input of said client data. 



The insurance transaction system of claim 15, wherein said rating information includes 
rates, rate formulas, and rate procedures and said development tools include a rating tool 
configured to enter and store in said database, for each product or policy of each 
insurance carrier, said rates, rate formulas, and rate procedures and selectively create 
associations between at least a portion of said rating information and said application 
interface initial and subsequent prompts. 

The insurance transaction system of claim 1 5, wherein said development tools include an 
underwriting tool configured to enter and store in said database, for a given carrier, said 
underwriting rules as logical formulas. 

The insurance transaction system of claim 1 5, wherein said development tools include a 
territory tool configured to associate one or more pre-existing insurance carrier territory 
codes, as part of said rating information, with one or more geographic Zip codes, wherein 
a territory code is indicative of the degree of risk associated with offering a given policy 
in a given geographical area. 

The insurance transaction system of claim 15, wherein said development tools include a 
violations tool configured, for auto, motorcycle, or boat insurance policies offered by a 
given carrier, to define and enter into the insurance transaction system one or more types 
of accidents and violations tracked by said carrier for the purpose of generating said rate 
quotes. 

The insurance transaction system of claim 15 wherein said insurance transaction system 
is capable of accessing, via said communication network, a third party violations database 
system having predetermined third party violation codes, and said development tools 
include a specific violation code mapping tool configured to map said third party 
violation codes to carrier specific violation codes in said database, for auto, motorcycle, 
or boat insurance policies offered by each carrier. 
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Ine insurance transaction system of claim 15, wherein said development tools include an 

unacceptable vehicles tool configured to define, as part of said rating information, for 
each insurance carrier, the make and model of each auto, motorcycle, and boat not 
insurable by said insurance carrier, for each auto, motorcycle, or boat insurance policies 
offered by said insurance carrier. 



A method for processing insurance transactions within an insurance transaction system 
having at least one workstation including a display screen and an input device, at least 
one database, and at least one application server interconnected via a communications 
network, wherein the database includes rating information and underwriting rules from a 
plurality of insurance carriers, the method including the steps of: 

A. prompting a user to select at said workstation a type of transaction from among a 
plurality of available transaction types, including: 

i. issuing a new policy, wherein a plurality of candidate policies are 

generated and displayed for selection of a preferred policy by the user; 
«. effecting a payment related to a policy; and 
iii. processing a claim against an existing policy; 

B. prompting the user to input at said workstation client data required by the 
insurance transaction system for the processing of the selected type of transaction, 
wherein subsequent prompts are dynamically generated as a function of the 
previously input client data; and 

C processing said selected transaction as a function of said client data and rating 
information. 

The method for processing insurance transactions of claim 25 wherein, when the selected 
type of transaction involves issuing anew policy of a selected insurance product type, 
step C includes: 

C-1 . generating, as a function of said user inputs, rating information, and 

underwriting rules, data representations, including rate quotes, of one or 
more candidate policies from the plurality of carriers; 

C-2. displaying at said display screen the candidate policies for comparison, if 
more than one candidate policy has been generated, and selection of a 

preferred policy from said one or more candidate policies by said user 
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1 0 using said input device; 

1 1 C-3. establishing in said database, as a function of the user's selection of said 

12 preferred policy, an issued policy corresponding to said preferred policy 

13 and correlated with said client; and 

14 C-4. generating and storing in said database an electronic billing schedule 

15 corresponding to said issued policy. 

1 27. The method for processing insurance transactions of claim 25, wherein the database 

2 includes rating information and underwriting rules for at least one other type of insurance 

3 product, and step C further includes: 

4 C- 1 . 1 . generating data representations of candidate companion policies 

5 from the plurality of carriers, as a function of said client data inputs 

6 and said rating information and underwriting rules, for at least one 

7 other type of insurance product. 

1 28. The method for processing insurance transactions of claim 25, wherein said workstation 

2 communicates with said application server via the Internet 

1 29. The method for processing insurance transactions of claim 25, wherein said workstation 

2 communicates with said application server via the World Wide Web. 

1 30. The method for processing insurance transactions of claim 25 wherein said workstation 

2 communicates with said application server via at least an extra-net or an intra-net. 

1 31. The method for processing insurance transactions of claim 25, wherein when the selected 

2 type of transaction involves effecting a payment, the step C includes: 

3 C-l . inputting at said workstation electronic funds transfer information, 

4 including a payment amount to be transferred from an identified financial 

5 account associated with said client and client policy identification 

6 information which identifies a policy in said database having a balance to 

7 which the payment is to be applied; 

8 C-2. applying said payment by electronically transferring said payment amount 

9 from said identified financial account to a carrier financial account 
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C * 3 ' rCCalcuIatin S said ba,an <* and generating a revised billing schedule as a 
function of the application of said payment. 
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The insurance transaction system of claim 31, wherein electronically transferring said 
paymentconstitutesat^^ 
deduction, direct payment, and electronic bill payment. 
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type of transaction is effecting a payment, step C includes: 
3 G-l. inputting at said workstation credit card information, including a payment 

^ amount to be credited from an identified credit card account associated 

with said client and client policy identification information which 
identifies a policy in said database having a balance to which the payment 
is to be applied; 

9 applying said payment by electronically crediting said payment amount to 

sa.d identified credit card account and transferring said payment amount to 
a carrier financial account associated with said policy; and 
recalculating said balance and generating a revised billing schedule as a 
function of the application of said payment. 
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C-2. 



C-3. 



The method for processing insurance transactions of claim 25, wherein a subset of said 
ratmg mformation and said underwriting rules in said database corresponds to a first 
earner from said plurality of carriers, the method further including: 
4 D. accessing remotely over the communication network said database by a first 

carrier; and 

updating said corresponding subset of rating information and underwriting rules 
in said database by said first carrier. 



5 

6 E.. 
7 



The method for processing insurance transactions of claim 25, wherein when the selected 
type of transaction involves processing an insurance claim in accordance with an existing 
pohcy lsS ued by an insurance carrier and stored in said database, a subject matter of said 
chum identifies the situation to be remedied or damage to be repaired under said claim, 
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5 and the database further includes information corresponding to a set of preferred 

6 providers for providing services related to remedying said situation or repairing said 

7 damage and a set of insurance adjusters for assessing the monetary claim value associated 

8 with said remedy or repair under said policy, step B includes: 

9 B-l . inputting at said workstation client claim data, including the subject matter 

10 of said claim and identification of the client's existing policy; and 

1 1 step C includes: 

12 C-l. generating and displaying at said workstation a preferred adjuster list from 

13 said set of preferred adjusters as a function of a set of predefined adjuster 

14 criteria and said claim data; 

1 5 C-2. generating and displaying at said workstation a preferred provider list from 

1 6 said set of preferred providers to said claim as a function of a set of 

1 7 predefined provider criteria and said claim data; and 

1 8 C-3. assigning, based on client selection at said workstation, at least one 

1 9 preferred adjuster from said preferred adjuster list and at least one 

20 preferred provider from said preferred provider list. 

1 36. The method for processing insurance transactions of claim 35, wherein step C further 

2 includes: 

3 C-4. electronically transferring an amount derived from said claim value from a 

4 carrier financial account of said insurance carrier to a preferred provider 

5 financial account of said preferred provider. 

1 37. A method of conducting insurance related transactions over the Internet using an 

2 insurance transaction system, each transaction being part of a session related to a specific 

3 client being serviced by an insurance agent using a workstation, having Internet access, to 

4 input client data and otherwise interact with said insurance transaction system, wherein 

5 said insurance transaction system includes: 

6 i. • a framework database system which includes and manages at least one 

7 dynamic database for storing session oriented data and at least one static 

8 database for storing at least a set of standard procedures, underwriting 

9 rules, and insurance carrier rate products; and 

10 ii. a core set of engines and servers, wherein said engines accomplish the 
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processing of sad insurance transactions using the data in said framework 

database system and wherein at least one server provides an interface 
between the Internet and said engines; and 
wherein said method includes the steps of: 

A. populating said static databases with said standard procedures, underwriting rules, 
and rate products for each of a plurality of insurance carriers; 

B. selectively designating, within said framework database system, at least one 
insurance agent having access and privileges to said insurance transaction system 
for processing insurance related transactions; and 

C accessing said insurance transaction system wjth said workstation and via the 
Internet by said insurance agent, inputting said client data, and selectively 
processing an insurance related transaction by accessing said core set of engines 
and servers. 



The method of conducting insurance related transactions of claim 37, wherein said agent 
is a franchisee located in a wholesale club. 

The method of conducting insurance related transactions of claim 37, wherein said 
insurance related transactions include generating a plurality of candidate policies and 
corresponding rate quotes for a client as a function of client data input by said agent at 
said workstation and related to said client and said standard procedures, underwriting 
rules, and rate products. 

The method of conducting insurance related transactions of claim 39, wherein said 
insurance related transaction includes issuing a preferred policy, selected from said 
plurality of candidate policies, and associating said preferred policy with said client in 
said framework database management system, and generating a billing schedule 
associated with said preferred policy. 
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The method of conducting insurance related transactions of claim 40, wherein said 
insurance related transaction includes accomplishing a payment of at least a portion of a 
premium associated with said preferred policy, including electronically transferring a 
payment amount from an account associated with said client to an account associated 
with a carrier of said preferred policy. 

The method of conducting insurance related transactions of claim 37, wherein said client 
data, said plurality of candidate policies, and said rate quotes are session oriented data 
stored in said dynamic database. 

The method of conducting insurance related transactions of claim 37, wherein said 
insurance related transactions include processing an insurance claim by said agent as a 
function of said input client data and an existing insurance policy issued to said client and 
providing coverage for said claim, wherein an adjuster for evaluating a monetary claim 
value associated with resolving said claim is chosen from a preferred adjuster database in 
said framework database system and a service provider for resolving said claim is chosen 
from a preferred provider database within said framework database system. 
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Action 


UQscrxpuon 


Bind 


Invoked when the Insurance Center creates a policy that contains temporary 

hillino information (Policv Status is Bind). 


CAN 


Cancel Flat - invoked when the policy is cancelled on renewal (e.g. the insured 
changes carriers on renewal). 


CLA 


Cancel Lost Account - invoked when a client changes agencies or carriers. 


CRW 


Cmr*c*\ p FMirrit/> _ iovoW^f! wh<»n a nolicv is cancelled due to non-payment, or 
when the insured chooses a new carrier. 


CTE 


Cancel Terminate - invoked when the insured is a member of a group 
(typically an employer group) which terminates its relationship with the 
insurance cujTicr. 


Endorsement 


invnirprf whpn the insured nurchases coverages typically excluded from the 
terms of the policy. 


Generate 


r\ pnpMtpc q Killina crhpHnle for a new rjolicv 


Issue 


Invoked when the insured purchases a new policy. A down payment had been 
mace. 


List 


Lists all policies for a specific client. 


New 


Invoked when a client applies for a policy. A billing schedule is generated and 
the billing schedule status is set to active. 


Pay Bill 


Invoked when the insured pays additional cash to an agent, who at the 
insured's request, applies the additional cash to a specific bill. 


Pay Next 


Invoked wnen me msureu pays a.ouuiondi tdin w an a^cui, wnv 
insured's request, applies the additional cash to the insured's next bill. 


Preview 


f _ . . _ i „ j _ _ _ i ts».. »Ua* />nntoine r»nl\/ tpmnnrarv I'M 1 1 in ty information* trie 
Invoked tor a policy inai comams oniy leiripui <u y uuimg uuuuuauuu« u<v 

policy status is left blank. 


Rec 


Invoked when the insured pays additional cash to the agent and the agent at 
rh» incurpH'c r«»ntipcr annlies the additional cash evenlv over the remaining 
length of time of me bill. 


Da* 

Kei 


Doinrtofo TnvntrArl whf»n th** injured reactivates the oolicv after the 
i\ein5iaie ™ lnvuivcu wucu u*v iu^iu tu iwaviivaiw um» p*-' » ,sr ^ ******* 

cancellation date, but prior to the five-day grace period. 


Renewal 

lWilv ww ill 


Invoked when an agent or Insurance Center employee wants to renew a policy. 


Rescind 


Invoked when the insured reactivates a policy prior to the cancellation date. 


Retrieve 


Invoked when an agent or Insurance Center employee wants to retrieve a 
policy for endorsement or display purposes. 


Upload 


Invoked for an account that is not billed by Insurance Center/carrier, but by a 
different Managing General Agent (MGA) who is responsible for the billing. 
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Components of BI 




Rating Element 




Calculation 


a. 


Base rate 


A. 


a x b (dollar rounded) 


b. 


Territory relativity 


B. 


A + c (if c applies, dollar rounded) 


c. 


Increased limit factor 


C. 


dxe. 


d. 


Primary class factor 


D. 


C x f (truncated to 3 decimals) 


e. 


Secondary class factor 


E. 


BxD (dollar rounded) 


f. 


Performance factor 


F. 


E x g (if g applies, dollar rounded) 


g. 


Clean driver discount. 


G. 


F x h (if h applies, dollar rounded) 


h. 


Multi-car discount factor 


H. 


G x i (if i applies, dollar rounded) 


i. 


Auto/Home discount factor 


I. 


H x j (if j applies, dollar rounded) 


j- 


Lay-Up credit 


J. 


I x k (dollar rounded) 


k. 


Term factor 
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M 


300/300 
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it 
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1.23 


» It 


300/500 


1.25 
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1.30 
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Rate Sequences 


Component 


Rate 
Sequence 


Base rate x Territory relativity - A 


10 


Primary class factor x Secondary class factor = C 


10 


A x Increased limit factor - B 


15 


C x Performance factor 


20 


BxD-E 


25 


E x Clean driver discount = F 


30 


F x Multi-car discount factor «■ G 


35 


G x Auto/Home factor = H 


40 


H x Lay-up credit = 1 


45 


I x Term factor = J 


60 


Perform the same component summation for Property Damage - Al 


60 


Perform the same component summation for PIP = Bl 


60 


Perform the same component summation for PPI = C I 


60 


Perform the same component summation for Collision - Dl 


60 


Perform the same component summation for Uninsured Motorist - El 


60 


Perform the same component summation for Towing, etc. - Fl 


60 


Add coverages A 1 + Bl +CI >D1 + EI + Fl 


70 


Sum any other factors/credits 


70 


Sum all components to derive the total premium 


80 
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Elements 


Element 


Coverage Choice 


Rate Factor 


Base rate 


N/A 


$48.52 


Coverage factor 


25/50 


0.90 


Territory relativity 


Territory 5 


1.0949 


Primary class factor 


35 years old/pleasure 


0.90 


Secondary class factor 


1 conviction point/1 at- faults 


1.30 


Increased limit factor 


This is a semi-annual credit 


$12.00 


Performance factor 


Intermediate performance 


1.15 


Clean driver discount ' 


None, because there are accidents 


1.0 


Multi-car discount factor 


None 


1.0 


Auto/Home factor 


Has a homeowner's policy 


0.95 


Lay-up credit 


Car is always used 


1.0 


Term factor 


Semi-annual calculations apply 


1.0 
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Sequence 


Math 


Result 


Base rate x Territory relativity = A 


10 


48.52 x L0949 


437 


Primary class factor x Secondary class factor = C 


10 


9x 1.30 


U7 


A + Increased limit factor = B 


15 


437+12 


449 


C x Performance factor = D 


20 


U7x 1.15 


2 


B x D = E 


25 


449x2 


898 


E x Clean driver discount - F 


30 


898 x 1 


898 


F x Multi-car discount factor = G 


35 


898 x 1 


898 


G x Auto/Home factor = H 


40 


898X.95 


853 


H x Lay-up credit =1 


45 


853 x 1 


853 


1 x Term factor - J 


60 


853 x1 


853 
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ONLINE QUOTATION SYSTEM ALLOWING FOR PARTIAL 
RESULTS VIEWING AND FULL RESULTS VIEWING 

BACKGROUND OF THE INVENTION 
The present invention relates to an online quotation system in general and 
5 in particular to methods and apparatus for generating partial quotations and full 

quotations, the partial quotations usually being prior to a user paying for the quotations 
and the full quotations usually being after a user pays for the quotations. 

With the increasing use of the Internet, a global internetwork of networks, 
many services have been developed to provide consumers (potential purchasers) with the 
1 0 ability to shop online to purchase products and services as well as to comparison shop. 
Some systems even allow potential purchasers to set a bid price for products or services. 

Insurance products and services have historically been among the most 
difficult types of products and services for consumers to shop for and purchase. 
Consumers have had to contact and/or meet with separate insurance companies and/or 
15 agents during normal work hours to compare the policies of different insurance 

companies. Even worse, consumers have had to provide the same purchasing variables 
multiple times to multiple insurance providers in order to do policy comparisons. As a 
result, the majority of consumers give up shopping for the best deal. 

One partial solution is provided by services that allow consumers to 
20 provide their purchasing variables once and receive policy information from a limited 
number of insurance companies at no charge. Some of those systems operate over the 
Internet. The current process for a typical service is inefficient because consumers must 
individually request policy information on a company-by-company basis and wait for a 
period of days to receive a significant portion of their policy comparison information by 
25 e-mail or regular mail. Moreover, the policy information they receive is often in 
hard-to-compare formats. In addition, certain of the price quotations received by 
consumers may not be competitive or otherwise appropriate for particular consumers. 

The typical Internet-based purchasing process is also inefficient for 
insurance providers because the insurance providers are responding to requests for policy 
30 information and quotes instead of requests for actual insurance policies. • This results in 
higher costs for many such insurance providers. Also, since consumers are not paying to 
receive this policy information from these multiple insurance providers, consumers have 
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much more of an incentive to shop for rather than actually purchase an insurance policy 
through existing Internet services, much like real estate shoppers that attend open houses 
and do not purchase. 

SUMMARY OF THE INVFNTTTON 
5 The present invention overcomes several disadvantages of the prior art 

used to provide quotations for products and services to consumers. In one embodiment, a 
computer system processes and provides quotations of prices to consumers for products 
or services by storing, in a server cluster coupled to a network, a database of quote data, 
wherein the database of quote data includes parameters relating to prices and other 
1 0 offering terms for the products or services being quoted. The database also includes 

contact information about an offeror of the products or services, the computer system also 
provides for accepting an input of purchaser variables, searching the database of quote 
data to identify products or services with offering terms that match the purchaser 
variables, generating a list of matched quotes, transmitting the list of matched quotes to 
1 5 the potential purchaser, prompting the potential purchaser to submit payment for the 
contact information for some or all of the matched quotes, following the step of 
transmitting the list of matched quotes and, if the potential purchaser submits payment for 
the contact information for matched quotes in the list of matched quotes, transmitting the 
list of matched quotes and associated contact information to the potential purchaser. In 
some embodiments, the consumer is charged one fee for all the contact information, but 
in others the consumer might be charged some nonconstant function of the number of 
quotes for which contact information is given. 

In one aspect of a specific insurance purchasing Internet server, the 
operator of the server maintains a network of agencies, where each member agency can 
provide insurance products to potential insureds. Using the server, a consumer can 
engage in insurance transactions with member agencies and the server can facilitate 
consumer fulfillment. The interaction and fulfillment can occur using the Internet server 
or by the consumer calling a call center. Preferably, the server and call center are 
integrated to provide a seamless and fully integrated method for many consumers to 
30 obtain insurance products. 
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A further understanding of the nature and advantages of the inventions 
herein may be realized by reference to the remaining portions of the specification and the 
attached drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a diagram of a quotation computer system according to one 
embodiment of the present invention. 

Fig. 2 is a block diagram of portions of the quoting system shown in Fig. 

1. 

Fig. 3 is a block diagram showing the processes and communications 
between a consumer client computer, a quote server computer and an agent server 
computer. 

Fig. 4 is a flowchart of a process for handling quotation services between a 
consumer client and a quote server. 

Fig. 5 is a flowchart of a process of interaction between a consumer client 
and an agent server for providing a policy following a quote from a quote server. 

Fig. 6 is a flowchart of a process for performing a consumer survey. 

Fig. 7 is a flowchart of a follow-up process performed by a quote server. 

Fig. 8 is a block diagram showing the processes and communications for 
providing quote data input shown in Figure 1 . 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
The present invention has many applications, as will be apparent after 
reading this disclosure. In describing an embodiment of a quotation system according to 
the present invention, only a few of the possible variations are described. Other 
applications and variations will be apparent to one of ordinary skill in the art, so the 
invention should not be construed as narrowly as the examples, but rather in accordance 
with the appended claims. 

The quotation computer system described below can be used to facilitate 
the process of providing, for example, insurance such as automobile, life or home 
insurance. A potential purchaser of insurance (the consumer) provides a quote server 
with purchaser variables. Purchaser variables are characteristics of the consumer that 
would affect the terms of a policy issued to that consumer. For example, if the insurance 
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is auto insurance, the purchaser variables might include driver name, driver age, driver 
gender, driver address (including state of residency), make of car, age of car, driving 
record, desired policy coverage amounts, etc. 

Those purchaser variables are used to match against agent/insurer criteria, 
to identify policies and terms (price, duration, coverage limits, etc.) for policies that the 
agent/insurer would provide to a policyholder described by the purchaser variables. This 
matching is done either by the quote server, using quote data provided by the agents or 
insurers, or by the agent servers. The matching can be done at the agent server, but more 
typically, the operator of the quoting system maintains a quote server. The quote server 
operates using data provided by insurance companies or by quote data aggregators. 

The potential purchaser is then presented with the list of matching quotes. 
A typical matching quote would indicate the essential terms of a policy and the premium 
to be paid. The matching quote might also indicate a customer satisfaction index. 
However, the list of matching quotes would not include the contact information, such as 
agent name or insurer name, associated with the quote. Optionally, the quote server 
might display a logo or an advertisement along with the agent name or insurer name. 
Such additional information might be displayed in all cases, or just when the agent or 
insurer requests the additional information be displayed, typically upon payment of a fee. 

The customer satisfaction index is a value that represents objective 
information about the insurer and the agent offering a policy. This infonnation might 
include the insurer's claims paying record and service ratings as well as the agent's 
service ratings. • 

With the quote server operator acting as the consumer's insurance broker, 
the consumer is prompted by the quote server to compare the premiums and other terms 

25 presented by the quote server with each other and with the consumer's current insurance 
terms, if any. The quote server might provide entry screens where the consumer enters 
the terms of current insurance, to facilitate the comparison. 

If the consumer likes one or more of the quotes, the consumer then pays to 
see the contact information associated with the quotes on the list. The consumer can then 

30 arrange for a policy with a selected agent, or a direct insurer if that insurer does not use 
agents. If the consumer follows certain procedures, such as binding within a set time 
period with an agent or direct insurer provided by the quote server operator, the quote 
server operator might provide a refund of all or a portion of the amount paid for the 
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quotes, or the agent or direct insurer might discount the premium by the amount paid, 
pursuant to an agreement with the quoting system operator. The agent or direct insurer 
agreement might also set out the fees to be paid to the quoting system operator for the 
referrals. 

5 Periodically, the quote server could automatically poll purchasers at 

random, such as by e-mail, to determine a satisfaction index for an agent or insurer. Also, 
prior to expiration of a policy, the quote server might automatically send out a prompting 
message to prompt the consumer to revisit the quote server's Web site and check for more 
current rates on new policies. 

1 0 The preferred embodiment includes agent filtering, but agent filtering is 

not a required function of the system. As the use of the quotation system becomes 
widespread, consumers will recognize the quotation system for its agent filtering. Agent 
filtering is the process of adding and removing agents based on objective indicia of agent 
performance. Using agent filtering, if multiple complaints are received from consumers 

1 5 relating to a specific agent, that agent's rating would go down and eventually the agent 
would be dropped from the contact list. Thus, the agent ratings could be used to direct 
consumers. 

On a basic embodiment, the quotes are listed in alphabetical order, in price 
order or in some other logical order apparent from the quotes themselves. In a variation 

20 of the basic embodiment, the quotes are presented in an order based on an agent rating, 
which might not be apparent or displayed. In such an embodiment, if the consumer 
selected a policy that could be obtained from more than one agent listed in an agent table, 
the consumer might be presented with contact information directing the consumer to the 
top-rated agent. Alternatively, the consumer could be provided with contact information 

25 for more than one agent and the ratings for those agents. With such information provided 
to consumers or used to order information presented to consumers, agents would have 
additional incentive to ensure that they provide the service necessary to maintain a high 
agent rating. 

In a specific embodiment, the total number of agents is limited to ensure 
30 that each listed agent receives enough business from the quoting system to remain 
responsive to consumers using the quoting system. 

A typical computer system for implementing such a quotation system is 
described below, in reference to the figures. 
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Fig. 1 is a diagram of a quotation computer system 100, comprising a 
client 102, a quote server 108, quote data input 1 10, a quoting system 106, agent servers 
1 1 2 (two such agent servers, 1 12(1) and 1 12(2) are shown) and network 1 14 used for 
handling communications among client 102 and servers 1 08 and 1 12. It should be 
5 understood that, while in a preferred embodiment network 1 14 comprises the Internet, 
other known methods of intercommunication could be used instead, such as a local area 
network, a wide area network, point-to-point dial-up connections, analog telephone, 
facsimile, or the like. Quote data input 1 10 is shown in FIG. 1 as removable media.' It 
should be apparent from this description however that quote data input 1 1 0 can be 
1 0 provided in a number of ways, such as transmission by modem or over a network 

connection to a file server or the Internet, or by original installation. The quote data can 
be provided by a quote aggregator or the insurance companies. A call center operation 
might also be used here, for consumers that have a telephone but not online access. 

In the call center operation, a consumer calls a call center operator at the 
call center 104. An interactive voice response unit (VRU) explains to the consumer how 
the call center operation works and indicates the charges to the consumer. The consumer 
is given an option to proceed and, if the consumer decides to proceed, the VRU requests a 
credit card or charge card number. The consumer is then charged for the quotes and is 
connected to a customer service representative, who takes the consumer's purchaser 
variables and generates a list of quotes with contact information. Where allowable, the 
call center might make arrangements with the consumer's telephone company to apply 
the charges to the consumer's telephone bill rather than use a credit card or charge card. 

One advantage to the consumer obtaining online quotes over telephone 
quotes is that the consumer can view the quotes (without contact information) prior to 
25 deciding whether or not to pay for the quotes. 

Client 102 is typically a computer capable of communicating over a 
TCP/IP (Transport Control Protocol/Internet Protocol) link using HTTP (HyperText 
Transport Protocol) messages. In a specific embodiment, client 102 includes an HTTP 
browser and quoting system 1 06 and agent servers) 1 12 include, at least, an HTTP server 
30 or other type of server. Other protocols besides TCP/IP and HTTP can be used instead 
for communications with client 102. 

Quoting system 106 is also coupled to a consumer background server 1 1 8. 
Consumer background server 1 18 is a computer system for providing consumer 
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background information, such as driving records, credit records and insurance claims 
history. Server 1 1 8 might be a collection of servers. For example, server 1 1 8 might 
serve credit data maintained by a credit reporting agency, driving record data maintained 
by a state department of motor vehicles and insurance information maintained by an 
insurance industry data collector, such as the CLUE insurance information system. 

Quoting system 106 can use the information provided by server 1 1 8 to 
select the proper policies and terms to present to the consumer. Quoting system 1 06 
might also provide an additional service to the consumer by allowing the consumer to 
view the information on that consumer at server 1 1 8 (for free, or for a fee) and provide 
instructions on how the consumer can correct erroneous information. Some quoting 
systems might allow a consumer to enter corrections directly and take those corrections 
into account in quoting insurance rates and policies, while others simply refer the 
consumer to the source of the information. 

Another use of server 1 1 8 (or the individual information maintainers 
enveloped by server 1 1 8), is for the insurance companies providing insurance. Once the 
information on a consumer is obtained by quoting system 106, it can be provided or sold 
to the consumer or to the insurer. Preferably, the insurance company is only provided 
information for those consumers that have selected that insurance company, however 
some of the consumer information might be needed before such selection, for example to 
calculate the prices to present prior to the payment for contact information. 

Fig. 2 is a block diagram of portions of the quoting system 106 shown in 
Fig. 1 . Quoting system 106 comprises program code 212 that is executable on processor 
210. Program code 212 may contain code for maintaining and processing data stored in 
session database 214, consumer database 216, products list 21 8, or agents list 220 and for 
communicating data to and from quote server 1 08 via communications path 1 1 6. 

Agent list 220 contains any contact, rating, and related information 
necessary or desirable to identify or describe the various local insurance agents associated 
with quotation computer system 100. Insurance products list 218 contains information 
regarding the various types of policies available such as auto, fire, life, liability or home 
or other property/casualty insurance. Consumer database 216 includes at least the 
necessary information to distinguish one particular potential purchaser from another and 
may contain precise information about specific quote requests, policies held, purchaser 
variables or other information. 
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In one embodiment, consumer database 216 is used by quoting system 106 
to determine when follow-up emails or updated quote information need to be sent to a 
consumer, for example, a birth date stored in consumer database 216 may be used to 
determine if the consumer has reached a particular age affecting his or her policy. In 
another embodiment, quoting system 106 utilizes consumer database 216 for accounting 
purposes between the operator of the quoting system and both the consumers and the 
agents/insurance providers for reasons such as to provide consumers with discount 
information or a refund of the payment provided by the consumer for contact information 
once a matching policy has been purchased. 

Session database 214 identifies a particular quote request transaction and 
contains a unique session identifier for each session. Session identifiers provide a means 
by which the quoting system can manage refunds or discounts for consumers who 
purchase policies from agents identified in the transmitted contact information as well as 
to identifying potential purchasers to those agents. Those having skill in the art will 
appreciate that the session identifiers can be put to other uses and the granularity of the 
session identifiers may vary depending on their use. For example, session database 214 
may be cross-referenced with consumer database 216, products list 218, and agent list 
220 to provide detailed information about a particular session, moreover, session IDs may 
include time stamping so that potential purchasers who did or did not pay for contact 
information or purchase from an agent provided by the quote system operator may be 
subsequently solicited by electronic mail or other means. 

In addition to communication path 1 16, quoting system 106 includes 
various other communications paths providing for the manipulation, storage, and loading 
of data including communications path 222 coupled to agent list 220, communications 
path 224 coupled to insurance products list 21 8, and communications path 226 coupled to 
consumer database 216. Data may likewise be transferred or edited using input 
communications path 228 and output communications path 230 coupled to I/O connector 
202. I/O connector 202 can accept and transmit data in various formats including but not 
limited to HTTP and facsimile by means of HTTP server 208, Fax server 206, and Call 
Center server 204. Although separate servers are illustrated for each individual data 
format it should be understood that other data formats as well as a single server capable of 
processing multiple message types may be employed. Input path 228 may accept quote 
requests from call center 104 and network 1 14 and may accept other information such as 
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quote data or consumer survey information. Output path 230 in turn may provide 
matching quote lists, contact information, and agent messages as shown. 

Fig. 3 is a block diagram showing the processes and communications 
between a consumer client computer, a quote server computer and an agent server 

5 computer. A consumer client within the system 300 first initiates a quote session when a 
quote request is issued. The session begins and a session identifier may be created upon 
receipt of the quote request within the quoting system 302. The quoting system may then 
reply to the request by preparing and transmitting a set of questions for the consumer 
regarding the insurance product desired, consumer information and preferences 304. 

1 0 These questions may then in turn be conveyed to the consumer by visual means such 
displaying them in a browser format or by audio or other means 306. 

Answers to the transmitted questions can be transmitted by the consumer 
and accepted by the quoting system so that consumer (purchaser) variables can be 
generated therefrom 308. It should be noted that the generation of questions and the 

1 5 receipt of answers may only be necessary when a consumer initially begins to use the 
quoting system or when updated information is required and that otherwise previously 
acquired and stored data may be used. However derived, the consumer variables are then 
transmitted to the quote server 310 which attempts to match the transmitted variables with 
quote data stored in its associated quote database 312. Any quote lists identifying 

20 matching quote data determined by the quote server are then forwarded to the consumer 
for review 314 and the consumer is prompted for payment to contact information 
associated with the transmitted quote lists 316. 

The quoting system next determines if consumer desires to remit payment 
for the desired contact information 3 1 8. In one embodiment, the receipt of a valid credit 

25 card or electronic currency identifier is used for this determination. If the consumer 
desires to remit payment and receive contact information associated with the previously 
transmitted quote list it is prepared by the quoting system 322 and transmitted to the 
consumer 326. To identify the completed 324 or discontinued 320 transaction, the 
previously generated session number is saved. 

30 It may thereafter be determined whether the consumer desires to use the 

provided contact information to purchase a product or policy from an agent identified in 
the transmitted list 328. At this point, the consumer may contact the agent directly or 
may desire that the agent or agents contact them regarding the desired policy. The 
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quoting system may then use the stored agent's contact information 332 to provide the 
consumer data and variables to the agent server desired 340 and may also provide a 
refund of the consumer's remitted payment 334. The consumer can then be notified of the 
refund 336 and the transaction completed 338. Session data would be recorded by the 
5 quoting system on any discontinued transactions 330 which could then be used by the 
quoting system, for example, to verify that a refund was appropriate if the consumer 
subsequently decided to use one of the quoting system listed agents. 

Fig. 4 is a flowchart of a process for handling quotation services between a 
consumer client and a quote server. The process is initiated 400 and the consumer 
1 0 information or identifier is accepted 402. A determination is then made based upon the 
accepted information whether the requesting consumer has previously requested 
information from the quote server 404. Existing customers may have their consumer 
variables updated 406, and new customers may provide their purchaser variables to 
provide quote data. In one embodiment, existing customers would be able to expedite the 
15 process by providing only that information requiring update or by communicating that no 
updates are required. It should be noted that although the use of a question and answer 
type form is depicted that alternative means of providing consumer data are also 
acceptable. User preferences and information may be stored within consumer client and 
uploaded to the quoting system described for comparison with existing consumer 
20 information or use. 

A quote list containing information related to quotes matching the 
transmitted consumer variables is then obtained from the quote server 410 and presented 
to the potential purchaser without contact information for insurers and/or agents 
associated with each matching quote 412 . If the consumer is willing to purchase the 

25 withheld contact information, and payment is verified, the contact information associated 
with the transmitted matching quotes is delivered to the purchaser 420. If the consumer 
then selects one of the provided agents to purchase a product or service from the session 
data is transmitted to the selected agent The transmitted session data may be used to 
identify what quote information was provided as well as to simplify contact and 

30 verification of the potential purchaser. In the event the potential customer either does not 
wish to purchase contact information related to the transmitted quote data or does not 
select one of the provided agents, the session data is stored so that the discontinued 
transaction may be resumed. A consumer can resume a session by entering enough 
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information to allow quote server 410 to match up the consumer with saved session data, 
or passwords could be used to match consumers with saved session data. 

Fig, 5 is a flowchart of a process of interaction between a consumer client 
and an agent server for providing a policy following a quote from a quote server. To 
identify the consumer and the quote data provided a session identifier is first transmitted 
to a selected agent server 502. The selected agent server can then determine if the quote 
data is accurate or if it needs to be supplemented or corrected to produce a finished quote 
504 which is then provided to the potential purchaser 506. At this point the potential 
purchaser may review the finished quote to determine if its terms are acceptable or if 
coverage is still desired 508. The consumer may either decline to purchase coverage, in 
which case the quote server is notified that no policy has been issued, or accept the 
finished quote. 

The agent may then bind coverage (provide a binder) 510 and a premium 
is collected 511. The policy is then issued to the purchaser 5 12 and the quote server is 
provided with information relating to the granted policy including the date coverage 
begins, the required premiums and the coverage provided 5 1 8. The premium can be 
collected in several ways. The agent can collect the premium from the consumer and then 
pass it on to the insurance company. However, it might be more efficient and secure for 
the premiums to be collected by the quotation computer system operator (subject to the 
operator being a licensed broker and otherwise complying with regulations surrounding 
premium collection). The collected premiums can then be aggregated and credited to the 
insurance companies providing the coverage. 

Fig. 6 is a flowchart of a process for performing a consumer survey. 
Consumer surveys may be provided to consumers for completion to improve the services 
provided as well as to rate and filter the associated agents to maintain quality service 
within the quote system described herein. In a preferred embodiment, consumer surveys 
are issued solely to consumers who hold policies with system-associated agents. Surveys 
may likewise be submitted to consumers who have paid to receive contact information 
but who failed to use it, or who viewed quote lists of matching quotes but who declined to 
purchase contact information however. After issuing a consumer survey 602, the quote 
server will read and store any information obtained from any completed surveys 608 and 
note and record any issued surveys not completed 610. 
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Fig. 7 is a flowchart of a follow-up process performed by a quote server 
In response to a determination that follow-up with an existing client is necessary 702 
updated purchaser variable information is obtained 704 and new matching quote data* 
generated, sent 706 and received by the consumer client 708. It will be appreciated that 
the follow-up determination itself be in response to a predefined event, such as the 
passing of an amount of time for selected existing consumers. 

Fig. 8 is a block diagram showing the processes and communications for 
providing quote data input shown in Figure 1. Although a third party data aggregator is 
depicted, it should be appreciated that other sources of quote data may be employed such 
as a local aggregation performed by the operator of the quotation computer system A 
third party, quote data aggregator, 800 is shown receiving as inputs insurance quote rules 
803 (two such quote rules, 803(1) and 803(2) are shown). Insurance quote rules 803 
comprise a collection of methods and formulas for generating quote data based upon 
vanables such as age, occupation, marital status, type of vehicle and driving record 
Quote rules may be generally applicable to various types or categories of coverage or 
specific depending on the type of coverage sought. Similarly, some insurance products 
may require specific variables in order to generate quote data using the associated rules 
803. The rules shown may also be from the same or different insurance providers Quote 
aggregator 800 compiles various insurance quote rules into aggregate database 802 
Quote server 1 08 may then access aggregate database 802 to generate and provide quote 
data. 

In summary, a computer system has been described that allows for 
comparative shopping for products and services. One category of products is financial 
services products, such as auto, fire, life, liability or home or other property/casualty 
insurance. When used as an msurance-providing computer system, the system couples 
agent servers, each associated with a particular agent selling insurance. In some cases 
the agents are assigned exclusivity based on purchaser variables, such as the geographic 
location of the consumer, but that is not required. Preferably, only one agent is connected 
to a given consumer for a given policy. The agent servers (and their associated agents) 
are included and excluded from the computer system as determined by the operator of the 
computer system. For example, an agent that fails to meet minimum service level 
requirements might be disconnected from the system. For some agents, the agent server 
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is nothing more than a facsimile machine that receives the consumer information from the 
quoting system. 

For agent servers that remain connected, the agent servers are provided 
with all or part of the set of purchaser variables (the quote server could opt to withhold 
5 some variables). In an alternate embodiment, the agents (or insurance companies) 

provide the quote data in bulk to the quote server operator so that quotes can be generated 
without contacting the agent server for each quote. However, if a consumer decides to 
follow through with one agent, that agent's server will receive all the purchaser variables 
that are needed to bind a policy and that are available at the quote server. 
1 0 Customer follow-up can also be performed by the quote server, to provide 

assurances that customers are receiving an acceptable level of customer service. One 
mechanism for customer service measurement is sending e-mailed customer surveys 
based on purchaser variables, such as date of policy purchase and consumer e-mail 
address. 

1 5 The customer survey might serve as a trigger to send a refund of the quote 

fees paid to obtain quotes. The initial quotes provided to a potential purchaser provide 
policy terms, policy premiums, satisfaction ratings for the agents and insurers, and 
general information about the insurer(s), but do not disclose contact information, such as 
the name of the agent or the insurer. The customer will then be able to compare the rates 

20 and other information to the customer's current policy before deciding whether or not to 
pay for the contact information. If the customer requests the contact information, the 
customer is charged a refundable service fee and shown the contact information. If the 
customer uses the computer system's agent network to purchase a policy, the service fee 
is refunded to the customer, either directly from the quote system operator (who is then 

25 paid by the agent/insurer) or as a discount on the policy premiums (where allowed by 
law). 

At predetermined intervals, the quote server will automatically send out 
prompts to purchasers prompting the purchaser to reconsider a policy. Other events, such 
as a change of address, change of driver age, change of vehicle or the like, might also 
30 trigger a prompt to reconsider. The purchaser might opt to limit the prompts only to cases 
where a change in premium would be more than a set amount of money or a set 
percentage savings over a current policy. 
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A method and apparatus for creating a seamless insurance system is 
disclosed above. With such a method or apparatus, consumers can shop for insurance 
products and the policies can be fulfilled in an integrated manner so that consumers can 
shop and obtain insurance more easily, with the quoting system operator acting as the 
consumer's broker. 

The above description is illustrative and not restrictive. Many variations 
of the invention will become apparent to those of skill in the art upon review of this 
disclosure. For example, the quotation server system for use in insurance sales is 
described in great detail. However, the quotation server system could also be used to 
provide automobile quotes, commodity consumer goods quotes, mortgage and home loan 
quotes, travel-related quotes (airlines, hotels, auto rentals, cruises), and the like. Tbe 
scope of the invention should, therefore, be determined not with reference to the above 
description, but instead should be determined with reference to the appended claims along 
with their full scope of equivalents. 
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WE CLAIM: 

1 . In a computer system for processing and providing quotations of prices to 
consumers for products or services, a method of providing a potential purchaser of the 
products or services with a quotation for the products or services, a method comprising 
the steps of: 

5 storing, in a server cluster coupled to a network, a database of quote data, wherein the 

database of quote data includes parameters relating to prices and other offering 
terms for the products or services being quoted and further includes contact 
information about an offeror of the products or services; 
accepting, at a quote server, an input of purchaser variables; 
10 searching the database of quote data to identify products or services with offering 

terms that match the purchaser variables; 
generating a list of matched quotes; 

transmitting the list of matched quotes to the potential purchaser; 
prompting the potential purchaser to submit payment for the contact information for 
15 one or more of the matched quotes, following the step of transmitting the list of 

matched quotes; 

if the potential purchaser submits payment for the contact information for one or 
more of the matched quotes, transmitting the list of matched quotes and 
associated contact information to the potential purchaser. 

20 2. The method of claim 1 , wherein the product is insurance and the purchaser 

variables are characteristics of the purchaser of insurance that affect at least one term of 
an insurance policy that an agent or insurance company could issue to a purchaser with 
those characteristics. 

3. The method of claim 1, wherein the step of prompting the potential purchaser to 
25 submit payment is a step of requesting a form of payment. 

4. The method of claim 1, wherein the step prompting the potential purchaser to 
submit payment is a step of requesting credit card identifiers. 

5. The method of claim 1, further comprising the steps of: 
arranging for purchase of a quoted product or service; and 
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refunding to the consumer all or a portion of the payment for contact information 
upon the consumer's purchase of the quoted product or service. 

6. The method of claim 1, wherein the quote data includes a set of rules used to 
identify products and services. 
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